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Executive  Summary 


Radically  different  approaches  to  software  acquisition  are  required  to  support  the  procurement 
of  mission-critical  systems  that  are  increasingly  dependent  on  software.  These  new  approach¬ 
es  are  also  necessary  to  take  advantage  of  the  most  current,  proven  technology  in  available 
software.  These  new  demands  must  be  met  despite  the  expectation  that  the  Air  Force  Elec¬ 
tronic  Systems  Center  (ESC)  will  radically  reduce  its  staffing  levels  over  the  next  two  years, 
and  that  additional  reductions  are  planned  in  the  future.  Given  a  severely  reduced  workforce, 
technical  and  management  techniques  will  be  necessary  to  meet  the  challenges  of  increased 
software  capability,  avoidance  of  obsolescence,  and  acquisition  of  software  intensive-systems 
of  increased  quality.  The  product  line  approach  described  in  this  Concept  of  Operations  is  one 
approach  that  can  meet  these  challenges  and  be  implemented  today. 

Lt  General  C.  E.  Franklin,  Commander  of  ESC,  has  stated: 

“ESC  programs  are  generally  variations  of  a  theme,  such  as  command  and 
control  centers,  communications  systems,  intelligence  centers,  etc....these 
product  line  systems  can  be  identified  in  the  future  year  development  plan 
process  and  can  be  represented  by  a  generic  architecture,  or  domain,  to 
facilitate  reuse  and  rapid  prototyping”  [FrankWn  94]. 

This  document  describes  the  Concept  of  Operations  (ConOps)  and  transition  strategy  for  the 
product  line  approach  to  software  systems  development  at  the  ESC,  Hanscom  Air  Force  Base, 
Massachusetts.  This  document  defines  the  organizations  implementing  the  product  line  ap¬ 
proach  and  the  processes  used  by  the  organizations.  It  describes  the  roles  and  responsibili¬ 
ties,  and  the  relationships  among  the  organizations.  The  processes  needed  to  implement 
software  system  development  using  the  product  line  approach  are  described  at  a  high  level 
and  will  be  further  detailed  and  refined  as  the  product  line  approach  is  implemented  at  ESC. 

A  product  line  for  software-intensive  systems  is  a  collection  of  systems  that  addresses  a  com¬ 
mon  set  of  system  requirements  for  a  particular  business  activity  or  mission.  Products  in  the 
product  line  are  customized  from  fundamental  requirements,  standard  product  line  architec¬ 
tures,  and  component  assets  rather  than  built  from  scratch.  The  System  Program  Office  (SPO) 
and  users  work  with  industry-supported  product  line  organizations  to  establish  their  needs. 
These  organizations  develop  systems  in  the  product  line  based  on  the  product  line  architec¬ 
ture  and  assets  and  deliver  systems  for  fielding  to  users. 

The  move  to  a  product  line  approach  will  require  changes  in  the  current  way  of  doing  business. 
To  reduce  redundancy,  the  product  line  approach  will  require  establishing  product  lines  for 
ESC  by  consolidating  engineering  capability  in  product  line  engineering  centers  managed  at 
the  Designated  Acquisition  Commander  level.  The  Government  will  take  responsibility  for 
product  line  architectures  and  other  assets  developed  by  the  engineering  centers.  The  SPOs 
can  depend  on  the  engineering  centers  for  general  engineering  services  and  cdntracts  for  sys¬ 
tem  delivery,  thus  allowing  the  SPO  to  concentrate  on  program  management  and  on  the  inter¬ 
face  with  users. 
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In  addition  to  establishing  product  lines,  the  product  line  approach  to  system  delivery  requires 
establishing  the  product  line  infrastructure  that  will  deliver  precedented  systems.  The  SPO, 
acting  as  acquisition  agent,  continues  to  provide  a  direct  interface  with  the  user  in  the  field  in 
making  the  decisions  to  procure  a  new  or  upgraded  system.  Working  with  the  product  line  en¬ 
gineering  centers,  the  SPO  and  the  user  are  the  customers  for  products  under  the  product  line 
approach.  They  remain  involved  throughout  the  development  and  can  monitor  and  validate 
the  system  as  it  evolves  from  prototype  to  final  deployment.  The  infrastructure,  including  the 
SPO,  user,  and  engineering  center,  sen/es  as  an  integrated  product  team  for  product  delivery. 

Figure  A  depicts  the  proposed  product  line  infrastructure  to  support  the  product  line  approach 
to  software  system  development  at  ESC.  Each  product  line  engineering  center  is  responsible 
for  one  or  more  product  lines,  and  as  the  product  line  approach  evolves,  the  engineering  cen¬ 
ters  will  evolve  with  the  addition  or  consolidation  of  product  lines.  In  addition  to  the  engineering 
centers,  two  other  product  line  organizations  will  support  the  approach: 

•  System  Architectures  Group  -  establishes  ESC-wide  product  line  processes, 
monitors  them,  and  works  with  product  line  and  related  organizations  to 
improve  them.  It  also  supports  product  line  development/evolution  and 
architecture  assessment  for  new  systems 

•  Product  Line  Asset  Support  Group  -  supports  asset  use  across  the 
engineering  centers. 

Table  1  shows  the  organizational  elements  that  participate  in  the  product  line  approach. 
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Element 

Primary  roles  and  responsibilities 

User 

•  defines  and  prioritizes  user  needs  and  clarifies  requirements 

•  analyzes  prototypes 

•  validates  prototype  results,  where  appropriate 

•  determines  which,  if  any,  of  the  original  requirements  can  be  tai¬ 
lored  to  conform  to  product  line  standards 

•  performs  acceptance  testing  of  delivered  systems 

•  uses  delivered  systems 

Program  Executive  Offi- 
ce(PEO)  and  Desig¬ 
nated  Acquisition 
Commander  (DAC) 

•  establishes  policy  for  product  line  systems  approach:  policy 
for  integrating  across  product  lines  and  interoperability 

•  ensures  all  programs  are  identified 

•  approves  identification  of  product  lines 

•  identifies  and  reserves  funds  for  product  line  creation  and  devel¬ 
opment 

•  approves  each  system  to  be  developed  under  the  product  line 
approach 

System  Program 
Office(SPO) 

•  manages  system  acquisition  and  development 

•  serves  as  the  primary  interface  to  users  and  between  other 
product  line  groups 

•  supports  product  line  identification 

•  uses  product  line  definition  to  assist  in  dialog  with  user  for 
deriving  operational  requirements  for  systems 

•  develops  plans  for  integration  across  product  lines 

•  manages  deployment  and  installation 

System  Architectures 
Group 

•  establishes,  monitors,  and  improves  the  ESC-wide 
processes  used  in  the  product  line  approach 

•  identifies  product  lines  with  SPOs 

•  with  engineering  centers,  SPOs,  and  users,  defines  and 
maintains  the  architectures  for  ESC  systems 

•  with  engineering  centers,  supports  the  evolution  and 
reengineering  of  legacy  systems  for  conformance  to  product 
line  architecture 

•  defines  standards  and  methods  for  validating  conformance 
with  architectural  definitions;  responsible  for  “building 
permits”  and  certifying  conformance 

Table  A:  Primary  Responsibilities  of  Product  Line  and  Related  Organizations 
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Element 

Primary  roles  and  responsibilities 

Product  Line  Engineer¬ 
ing  Center 

•  defines  and  maintains  architectures  for  product  lines  within 
the  engineering  center  and  for  integration  across  product 
lines 

•  develops,  procures,  and  evolves  software  (including  COTS 
software)  for  product  lines  and  for  product  line  assets; 
configuration  management 

•  integrates  and  delivers  systems  by  tailoring  the  product  line 
architecture,  specialization,  and  custom  development  per 

SPO  requirements 

•  supplies  domain  expertise  in  key  product  line  technology 
areas 

•  provides  contract  vehicle  for  use  by  SPO  for  product  delivery 

Product  Line  Asset  Sup¬ 
port  Group 

•  qualifies  products  against  product  line  architectures 

•  identifies  enterprise-wide  assets  (from  COTS,  GOTS, 
product  line  engineering  centers) 

•  provides  a  repository  for  ESC-wide  engineering  center  use 

Table  A:  Primary  Responsibilities  of  Product  Line  and  Related  Organizations 

To  implement  the  product  line  approach  defined  here,  ESC  should  take  the  following  steps: 

•  designate  a  product  line  agent  within  ESC/AX,  the  acquisition  organization  at 
ESC,  to  champion  the  product  line  concept  and  ensure  successful 
implementation  of  product  lines  for  ESC 

•  provide  a  forum  for  discussion  of  product  line  concepts  with  users  and  SPOs 
to  inform  them  of  strategy  and  of  new  and  evolving  needs  to  understand 
product  line  requirements 

•  establish  a  concept  of  operations  and  processes  for  the  System 
Architectures  Group,  Asset  Support  Group,  and  Product  Line  Engineering 
Centers 

•  develop  a  transition  plan  for  each  product  line  organization 

•  use  the  Command  and  Control  Product  Lines  (CCPL)  Program  as  the  test 
case  for  the  product  line  engineering  center  approach 

•  establish  programs  similar  to  CCPL  for  other  product  lines 

•  produce  an  implementation  plan  for  each  product  line  including:  process 
definition;  what  will  be  developed  (product  line  identification,  product  line 
architectures);  business  analysis  (when,  what  costs,  milestones,  etc.);  and 
measurement  and  tracing 

This  approach  represents  the  leading  edge  of  acquisition  reform.  The  strategy  described  in 
this  ConOps  represents  a  dramatic  change  in  the  ESC  approach  to  the  procurement  of  prece- 
dented  systems.  It  is  an  approach  that  accelerates  the  acquisition  process  while  providing  in¬ 
creased  predictability  and  quality  at  lower  cost. 
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Concept  of  Operations  for  the  ESC  Product  Line  Approach 


Abstract:  This  document  describes  the  Concept  of  Operations  (ConOps)  and 
transition  strategy  for  the  product  line  approach  to  software  systems  develop¬ 
ment  at  the  Air  Force  Electronic  Systems  Center  (ESC),  Hanscom  Air  Force 
Base,  Massachusetts.  This  document  defines  the  organizations  implementing 
the  product  line  approach  and  the  processes  used  by  the  organizations.  It  de¬ 
scribes  the  roles  and  responsibilities,  and  the  relationships  among  the  organi¬ 
zations.  The  processes  needed  to  implement  software  system  development 
using  the  product  line  approach  are  described  at  a  high  level  and  will  be  further 
detailed  and  refined  as  the  product  line  approach  is  implemented  at  ESC. 

1  Introduction 

A  product  line  for  software  is  a  collection  of  software  systems  that  addresses  a  common  set 
of  system  requirements  for  a  particular  business  activity  or  mission.  The  development  of  soft¬ 
ware  in  the  product  line  is  characterized  by  the  use  of  common  assets  including  product  line 
architectures,  components,  and  process  models.  Products  in  the  product  line  are  built  using 
these  common  assets  plus  some  system-unique  software. 

Under  the  product  line  approach,  the  System  Program  Office  (SPO)  provides  direct  interface 
with  the  user  in  making  the  decisions  to  procure  a  new  or  upgraded  system.  Working  with  in¬ 
dustry-supported  product  line  organizations,  the  SPO  and  the  user  are  the  customers  for  prod¬ 
ucts.  They  remain  involved  throughout  the  development  and  can  monitor  and  validate  the 
system  as  it  evolves  from  prototype  to  final  deployment  (Figure  1 ,  Part  a).  Rather  than  building 
from  scratch,  the  product  line  organizations  engineer  products  in  the  product  line  through  cus¬ 
tomization  from  base  requirements  and  standard  product  line  architectures,  and  integration  of 
components  and  system-unique  software.The  infrastructure,  including  the  SPO,  users,  and 
product  line  organizations,  will  serve  as  an  integrated  product  team  for  product  delivery.  Figure 
1 ,  Part  b,  illustrates  this  concept.  As  part  of  an  overall  plan  for  acquisition  reform,  ESC  is  pro¬ 
moting  a  product  line  approach  to  systems  acquisition.  Lt  General  C.  E.  Franklin,  Commander 
of  ESC,  has  stated: 

“ESC  programs  are  generally  variations  of  a  theme,  such  as  command  and 
control  centers,  communications  systems,  intelligence  centers  etc....these 
product  line  systems  can  be  identified  in  the  future  year  development  plan 
process  and  can  be  represented  by  a  generic  architecture,  or  domain,  to 
facilitate  reuse  and  rapid  prototyping”  [FrankYm  94]. 

A  team  comprised  of  ESC,  MITRE,  and  Software  Engineering  Institute  (SEI)  representatives 
produced  the  Product  Line  Identification  for  ESC-Hanscom  [Cohen  95]  which  recommended 
a  product  line  organizational  structure  to  support  the  product  line  approach  to  software  system 
development  at  ESC.  This  organizational  structure  is  managed  by  the  ESC  Designated  Acqui¬ 
sition  Commander  (DAC).  The  organizational  structure  described  in  that  report  has  since 
evolved.  The  new  structure,  revised  by  Lt  Gen  Franklin,  is  depicted  in  Figure  2. 
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Figure  1 :  Product  Line  Concept  of  Operations 


Figure  2:  Proposed  ESC  Product  Line  Organizational  Structure 
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Three  key  organizations  work  with  a  SPO  and  user  to  produce  the  system; 

•  System  Architectures  Group  (SAG)  supports  product  iine  architecture 
definition  with  the  Product  Line  Engineering  Centers  for  ESC  product  lines. 
The  architecture  group  helps  establish  criteria  used  by  the  Asset  Support 
Group  for  suitability  testing  of  commercial  and  government  off-the-shelf 
software.  The  architectures  group  also  collaborates  in  building  specific 
applications  by  recommending  a  product  line  source  to  the  SPO  based  on 
SPO  requirements  and  by  analyzing  needs  and  tailoring  the  product  line 
architecture  for  production  of  the  application. 

•  Product  Line  Engineering  Center  (PLEC)  defines  and  evolves  product  line 
architectures  with  the  SAG.  The  PLEC  is  also  tasked  by  the  SPO  to  develop 
prototypes  where  appropriate,  and  produce  a  development  plan  (Program 
Execution  Plan)  for  product  line  development  of  a  system.  The  engineering 
center  provides  a  contract  vehicle  that  the  program  office  uses  with  a 
contractor  to  develop  and  deliver  systems  through  the  development  phase  to 
the  customer.The  engineering  centers  also  develop  assets  and  perform 
configuration  management  for  use  within  their  own  product  lines. 

•  Product  Line  Asset  Support  Group  (PLAS)  supports  reuse  of  components 
through  asset  identification,  packaging,  and  qualification  as  the  basis  for 
product  line  development/sustainment.  With  the  architecture  group  and 
engineering  center,  ensures  successful  use  of  asset  base  in  and  across 
product  lines.  This  includes  supporting  asset  development  in  the  engineering 
center  and  direct  asset  development  and  configuration  management  for 
cross-product  line  assets. 


1.1  Scope 

This  report  describes  the  Concept  of  Operations  (ConOps)  for  the  product  line  approach  to 
software  systems  development  at  the  Electronic  Systems  Center  (ESC),  Hanscom  Air  Force 
Base,  Massachusetts.  This  document  defines  the  organizations  implementing  the  product  line 
approach  and  the  processes  used  by  the  organizations.  It  also  describes  the  roles  and  respon¬ 
sibilities,  and  the  relationships  among  the  organizations. 

The  intent  of  the  report  is  to  provide  the  concepts  required  to  understand  the  product  line  ap¬ 
proach  to  development.  This  report  is  not  intended  to  be  an  implementation  or  transition  plan. 
The  report  explains  some  of  the  key  issues  involved  in  the  transition,  but  does  not  provide 
managers  with  the  detailed  steps  involved  in  planning  for  the  transition,  including  establishing 
accountability,  managing  risk,  scheduling,  and  budgeting.  These  must  be  considered  when 
transitioning  to  the  product  line  approach  and  setting  up  the  product  line  organizations  to  im¬ 
plement  the  approach. 

Readers  of  this  report  should  be  familiar  with  the  Software  Reuse  Initiative  Reuse  Methodol¬ 
ogy  Fusion  Framework  (RMFF)  Final  Report  [Haddad  96]  and  understand  the  current  DoD  ac¬ 
quisition  policy. 
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1.2  ConOps  Overview 

This  ConOps  includes  the  following  sections: 

•  Section  2  provides  the  reasons  for  moving  from  a  program  orientation  to  the 
product  line  systems  approach. 

•  Section  3  elaborates  the  functions  of  the  SPO,  PLEC,  SAG,  and  PLAS  and 
offers  scenarios  for  asset  and  system  development. 

•  Section  4  outlines  the  ESC  Product  Line  transition  strategy. 

•  Section  5  provides  an  analysis  of  the  advantages  and  challenges  of  the  new 
approach. 
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2  Rationale  for  Change 

With  the  current  acquisition  process,  it  is  not  unusual  for  major  systems  to  require  7  to  1 0  years 
to  progress  from  conceptualization  through  research  and  development,  design,  integration 
and  test  to  deployment.  We  are  continuing  to  relearn  lessons  in  each  development,  and  we 
are  not  taking  advantage  of  improved  reliability,  common  operations,  and  training. 

Radically  different  approaches  are  needed  to  continue  to  meet  the  demand  for  increased  soft¬ 
ware  functionality,  at  a  time  when  the  Air  Force  has  less  money  and  staff  to  accomplish  this 
task.  ESC  is  expected  to  reduce  significantly  overall  staffing  levels  in  the  next  two  years.  To 
meet  these  challenges,  a  range  of  techniques  and  technologies  are  emerging  and  being  en¬ 
dorsed  by  the  Department  of  Defense  (DoD).  One  of  these  is  the  product  line  approach. 

The  product  line  approach  can  offer  specific  advantages  over  a  project-oriented  development 
strategy.  Development  time  and  cost  are  significantly  reduced.  Organizations  build  core  com¬ 
petencies,  which  are  concentrated  areas  of  knowledge  that  allow  them  to  make  more  produc¬ 
tive  use  of  their  staff.  Products  are  engineered  through  recognition  of  changes  within 
fundamental  requirements  or  product  line  architectures,  rather  than  built  from  scratch.  In  ad¬ 
dition,  under  the  product  line  approach,  ESC  can  provide  specific  guidance  to  suppliers  for 
vendor  qualifications,  development  standards,  and  product  definitions. 

The  product  line  approach  to  developing  and  maintaining  DoD  systems  is  supported  by  the 
Office  of  the  Secretary  of  Defense.  The  Air  Force  is  currently  planning  to  implement  product 
lines,  consistent  with  direction  and  guidance  from  the  DoD.  A  product  line  strategy  is  consis¬ 
tent  with  and  complements  the  ongoing  acquisition  reform  and  streamlining  initiatives  within 
the  Air  Force  [Perry  94] [Lightning  Bolt]. 

By  exploiting  commonalities  and  controlling  the  variabilities  across  related  systems,  the  USAF 
can  develop  strategies  that  will  enable  the  fielding  of  these  systems  faster,  cheaper,  and  with 
added  capability  for  the  war  fighter.  For  the  product  line  concept  to  work,  there  is  a  fundamen¬ 
tal  change  required  in  the  way  system  requirements  are  defined.  Users  must  be  aware  that 
the  product  line  approach  will  produce  a  “less-than-100%”  solution  for  their  initially-stated  re¬ 
quirements.  The  users  must  also  be  aware  that  they  will  be  called  upon  to  decide  on  the  trade¬ 
offs  associated  with  the  elimination  of  some  of  these  requirements. 

Within  this  constraint,  the  product  line  approach  will  result  in 

•  consolidation  of  core  resources  and  competencies  through  identification  of 
key  business  areas 

•  increased  quality  through  the  use  of  assets  that  are  well  understood  and 
proven  through  retesting  during  multiuse 

•  building  of  tailorable  features  into  assets  to  meet  more  than  one  user’s  needs 

•  minimizing  of  number  of  assets  -  reducing  overall  and  repetitive  development 
costs 
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•  reduction  of  risk  in  software  performance  through  known  performance  of 
assets 

•  improved  time  to  production  through  reuse  of  technology,  design,  and  assets 

•  increased  interoperability  through  reuse  of  common  architectures, 
interfaces,  and  protocols 

•  reduced  training  requirements  for  operations  and  O&M  through  similarities  of 
components 
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3  Product  Line  Concept 

This  section  presents  separately  the  concepts  for 

•  the  role  of  architecture 

•  the  management  of  product  line  assets  including  the  product  line  architecture 

•  the  development  of  systems  in  the  product  line 

This  section  also  includes  scenarios  for  product  line  asset  development  and  product  line  sys¬ 
tem  production. 


3.1  The  Role  of  Architecture 

The  product  line  architecture  provides  the  structure  for  building  systems  in  the  product  line. 
The  architecture  is  critical  to  the  success  of  the  product  line  approach.  Key  product  line  deci¬ 
sions  are  made  during  the  process  of  developing  or  selecting  the  product  line  architecture. 
These  include 

•  What  are  the  critical  issues  in  product  line  development  (product  line 
selection  and  inclusion,  handling  commonalities  and  differences,  security, 
interoperability,  reliability  in  product  delivery)? 

•  How  will  the  product  line  support  interoperability/component  integration 
issues  (e.g.,  the  Defense  Information  Infrastructure-Common  Operating 
Environment  (Dll-COE)  technical  architecture)?  Compliance  and  levels  of 
compliance 

-  legacy  systems 

-  new  development 

•  What  are  the  plans  for  change/evolution  management  within  the  product 
line? 

•  What  are  the  key  quality  factors  (for  example,  performance,  security, 
dependability)  that  are  essential  for  the  product  line? 

•  How  will  the  product  line  take  advantage  of  COTS/software  sharing? 

•  How  will  systems  be  built  (operational,  system,  and  technical  architectures)? 

Before  establishing  the  product  line  architecture,  ESC  must  take  an  enterprise-wide  look  at 
the  organization’s  products.  A  first  step  is  segmenting  these  products  into  product  lines 
through  an  identification  and  scoping  process  such  as  that  described  in  the  RMFF  report  [Had¬ 
dad  96].  Mission  area  analysis  to  define  the  organization’s  business  and  the  development  of 
the  organizational  structure  for  product  line  development  is  a  part  of  this  step.  The  next  steps 
in  the  decision  process  include  product  line  specification,  development  of  a  product  line  archi¬ 
tecture,  and  system  architecture  design  for  the  individual  product. 

•  Specification  of  the  product  line.  Specification  requires  understanding  the 
potential  commonalities  across  current  and  future  systems  in  the  product  line 
as  well  as  variations  that  lead  to  different  systems.  This  key  step  requires 
analysis  of  product  line  capabilities,  those  that  are  mandatory  for  each 


CMU/SEI-96-TR-018 


7 


system  in  the  product  line,  and  those  that  may  be  optional.  In  addition,  the 
definition  must  provide  for  alternative  capabilities,  i.e.,  a  choice  among 
different  capabilities,  where  appropriate. 

•  Development  of  a  product  line  architecture.  The  product  line  architecture 
defines  the  components  (mandatory,  optional,  alternative),  component 
interrelationships,  constraints,  and  guidelines  for  use  and  evolution  in 
building  systems  in  the  product  line.  The  product  line  architecture  must 
support  common  capabilities  identified  in  the  specification  and  the  potential 
variabilities  within  the  product  line.  The  product  line  architecture  provides 
various  views  into  the  product  line,  including  data,  security,  performance,  and 
communication.  This  step  will  identify  existing  architectures  and  architecture 
fragments  (component  designs)  that  can  be  reused  in  new  and  updated 
product  line  architectures.  Product  line  architecture  guidelines  will  include 
factors  for  the  use  and  evolution  of  the  architecture. 

•  System  architecture  design.  The  SPO  will  select  representatives  from  the 
product  line  organizations  to  form  a  product  line  architecture  selection  team. 

This  team  collaborates  in  product  line  production  to  determine  architecture 
suitability  for  a  new  system.  The  team  must  assess  the  ability  of  the  product 
line  architecture  to  meet  the  specific  system  needs  as  defined  by  the  user 
and  SPO.  This  architecture  assessment  considers  existing  products  in  the 
product  line  as  well  as  architectural  constraints. 

Existing  products  may  serve  as  a  model  for  the  new  system,  or  the  product 
line  assets  may  support  a  prototyping  capability.  The  architecture  team  must 
determine  if  the  new  system’s  needs  can  be  met  within  the  current  product 
line  architecture.  If  not,  they  must  decide 

a.  if  the  system  needs  can  be  relaxed,  so  that  the  product  line 
architecture  can  be  used 

b.  if  it  is  feasible  to  use  parts  of  the  product  line  architecture  or  to  extend 
it  for  this  new  need  and  for  future  systems  in  the  product  line 

They  may  decide  that  system  development  cannot  be  performed  with  the 
product  line  approach  and  then  employ  alternate  acquisition  methods. 

The  architecture  group  works  together  with  the  SPOs  and  the  engineering  centers  to  develop 
product  line  architectures  based  on  user  needs.  Figure  3  shows  the  architecture  tasks  that  are 
part  of  product  line  architecture  specification  and  those  used  in  developing  specific  system  ar¬ 
chitectures. 

Within  both  the  product  line  and  system  architecture  design  activities,  it  is  necessary  to  ad¬ 
dress  three  key  architectural  considerations:  product  line  requirements,  physical  hard¬ 
ware/software  configuration  and  constraints,  and  architectural  standards.  These 
considerations  lead  to  the  operational,  system,  and  technical  architectures.  [Horizon  95][Had- 
dad  96] 
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•  Operational  architecture  -  refiects  users’  activities;  describes  system 
organization  and  interfaces,  functional  activities,  data  models,  reusable 
components,  and  performance  aspects  such  as  volume,  timeliness  and 
sensitivity. 

•  System  (physical)  architecture  -  the  fielded  automated  system;  physical 
nodes  and  linkages  represented  by  facilities,  sensors,  communications,  and 
computer  systems. 

•  Technical  architecture  -  technical  framework  and  set  of  rules  from  which 
automated  systems  can  be  developed;  standards  and  common 
interfaces.The  Dll  COE  technical  architecture  is  an  example. 

Architectural  tradeoffs  among  these  concerns  stem  from  differing  mission  needs,  threats,  or 
specific  operational  requirements.  They  are  essential  to  the  product  line  and  system  architec¬ 
ture  design  activities  and  are  also  important  considerations  for  interoperability  and  standard¬ 
ization.  Figure  4  shows  these  activities  contributing  to  the  architecture  design  activity  where 
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standards  such  as  Dll  COE  will  influence  system  physical  designs  and  drive  application  archi¬ 
tectures.  End-user  systems  will  demonstrate  the  viability  of  the  standards  and  indicate  areas 
for  improvement. 


3.2  Product  Line  Assets 

Product  line  assets  are  the  reusable  resources  that  support  the  development  of  products  in  a 
product  line.  These  assets  are  more  than  just  software  components.  They  include 


domain  models 

product  line  architectures 

communication  protocol  descriptions 

user  interface  descriptions 

code  components 

work  breakdown  structures 

application  generators 

process  components  (methods,  tools) 

designs,  design  standards,  design  deci¬ 
sions 

Each  development  cycle  of  a  system 

assets. 


domain  knowledge 
test  plans  and  procedures 
requirement  descriptions 
CM  plans  and  tools 
performance  models,  metrics 
budgets  and  schedules 
prototypes 

COTS  product  profiles 
test  scaffolding 

line  offers  an  opportunity  to  refine  these 


in  the  product 
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3.2.1  Asset  Support  Activities 

The  activities  required  to  identify  and  maintain  product  line  assets  include 

•  identifying,  qualifying,  and  packaging  reusable  resources  (enterprise-wide 
assets)  for  use  in  future  development 

•  making  them  available  within  and  across  product  lines  at  ESC  (through  a 
repository  and  other  communication  channels) 

•  maintaining  configuration  control  on  versions 

And,  in  the  case  where  a  product  line  has  made  the  commitment  to  leverage  commercial  in¬ 
vestment  by  focusing  on  the  integration  of  COTS  products  as  a  development  method,  it  will  be 
necessary  to  have  the  infrastructure  in  place  to 

•  perform  suitability  testing  of  COTS  products  using  a  centrally-maintained 
facility 

The  Product  Line  Asset  Support  Group  is  primarily  responsible  for  performing  these  tasks  un¬ 
der  this  Concept  of  Operations.  However,  the  asset  group  is  supported  by  the  other  product 
line  organizations.  For  example,  in  identifying  enterprise-wide  assets,  the  architecture  group 
will  play  a  major  role  as  part  of  its  task  in  developing  product  line  architectures.  This  is  espe¬ 
cially  the  case  for  ESC-specific  assets.  For  COTS  products,  the  asset  group  will  remain  the 
major  source  for  identifying  and  determining  suitability  of  assets;  however,  the  original  con¬ 
tractor/developer  retains  responsibility  for  its  own  assets.  Figure  5  shows  the  relationship  of 
these  activities  to  the  other  product  line  organizations. 


Architecture  Group 
£n^i|ieeri|i|[  Cei  it  ^ 
Asset  Support 


Engineering  Centers 
Architecture  Group 
SPOs 


Engineering  Centers 
Architecture  Group 
Vendors 


Architecture  Group 

Engineering  Centers 

Vendors  Approved 
Product  List 

SPOs 


Figure  5:  Product  Line  Asset  Support  Group  Interactions 
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Identify  Enterprise-Wide  Assets 

An  important  core  product  line  effort  involves  the  identification  of  reusable  assets  for  use  within 
and  across  product  lines  and  the  development  of  a  reusable  asset  base.  Legacy  systems  must 
be  analyzed  to  identify  and  repackage  existing  software  for  possible  use  as  reusable  informa¬ 
tion  and  assets.  Assets  from  legacy  systems  and  new  development  include  software,  archi¬ 
tectures,  designs,  criteria,  and  other  information.  This  information  will  be  maintained  in  a 
product  line  asset  repository.  Identification  and  packaging  of  these  enterprise-wide  assets  will 
increase  the  asset  base  available  to  each  product  line  organization. 

Another  ongoing  task  to  support  the  identification  and  distribution  of  enterprise-wide  assets  is 
cross-product  line  analyses  of  these  assets  to  identify  opportunities  for  reuse  of  products  and 
knowledge  in  other  product  lines.  Technology  transfer  of  this  information,  as  well  as  emerging 
reuse  techniques  and  methods  across  product  lines,  will  be  performed  to  maximize  the  bene¬ 
fits  of  the  opportunities  identified. 

Repository 

A  repository  of  product  line  information  acquired  through  suitability  testing  and  identification  of 
enterprise-wide  assets  activities  will  be  maintained.  This  will  include  all  of  the  kinds  of  assets 
stated  above,  organized  according  to  the  product  lines.  ESC-sensitive  information  will  be 
available  through  an  access-controlled  repository.  A  list  of  the  products  tested  and  the  results 
of  suitability  testing  will  be  made  available  through  a  separately-maintained  Product  List. 
Eventually,  an  acquisition  mechanism  for  COTS  products  may  be  provided  in  addition  to  the 
Product  List. 

The  asset  repository  will  accelerate  and  support  availability  of  proven,  reliable  assets  for  in¬ 
corporation  into  product  line  systems.  As  the  repository  is  fully  populated  and  the  working  re¬ 
lationships  among  the  organizations  mature,  the  opportunities  for  reuse  will  increase  and  the 
benefits  of  the  product  line  approach  will  be  realized. 

Suitability  Testing 

Suitability  testing  is  the  process  of  determining  if  a  COTS  or  Government  off-the-shelf  (GOTS) 
software  product  meets  the  architectural  and  functional  requirements  of  a  component  area 
within  a  software  architecture.  The  products  are  tested  using  a  standard  process  to  provide  an 
objective  analysis  of  the  functionality  and  architectural  capabilities  using  criteria  that  are  de¬ 
rived  from  the  architecture.  COTS  and  GOTS  products  will  be  tested  for  suitability  against 
product  line  architectures.  Suitability  criteria  will  be  developed  and  maintained.  The  suitability 
criteria  are  derived  from  requirements  and  interfaces  for  component  areas  in  product  line  ar¬ 
chitectures,  and  are  used  to  perform  suitability  testing  of  software  products.  Results  of  suitabil¬ 
ity  testing  will  be  placed  in  the  Approved  Product  List. 

More  complete  information  on  product  line  asset  support  activities  is  available  in  the  Product 
Line  Asset  Support  Concept  of  Operations  [Solderitsch  96]. 
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3.3  The  Development  of  Systems  in  a  Product  Line 

The  process  for  developing  systems  under  a  product  line  approach  differs  from  the  current 
process  in  two  ways.  These  are 

1 .  Development  from  standard  architectures  -  A  group  of  related  systems 
shares  a  common  structure  defined  as  a  product  line  architecture.  In  addition 
to  structural  properties,  the  product  line  architecture  defines  the  components 
(mandatory,  optional,  alternative),  component  interrelationships,  constraints, 
and  guidelines  for  use  and  evolution  in  building  systems  in  the  product  line. 

This  architecture  must  support  interoperability  and  component  sharing  with 
systems  developed  outside  the  product  line.  A  new  system  is  built  by  tailoring 
the  product  line  architecture  based  on  user  requirements  to  produce  a  system 
architecture. 

2.  Development  using  product  line  assets  -  New  systems  are  composed, 
adapted,  or  generated  by  populating  the  system  architecture,  to  the  greatest 
degree  possible,  with  existing  product  line  assets.  This  approach  to 
development  includes  formal  tracking  of  the  product  line  assets  and 
identification  of  opportunities  for  reuse  of  the  assets  in  other  product  lines. 

The  new  system  architecture  and  any  developed  or  modified  assets  become  core  assets  for 
future  development  in  the  product  line. 


3.3.1  Working  with  the  User 

The  System  Program  Office  takes  on  a  new  role  under  a  product  line  approach.  The  SPO  con¬ 
tinues  to  work  with  users  to  define  operational  requirements  and  deploy  systems,  but  uses 
task  order  contracts  available  though  the  engineering  center  to  develop  and  deploy  these  sys¬ 
tems.  The  SPO  also  relies  on  the  product  line  engineering  center  to  provide  domain  expertise 
in  key  technology  areas,  such  as  radar,  communications,  and  network  control.  Developing  the 
expertise  within  the  engineering  center  and  the  assets  that  embody  that  expertise  will  be  fund¬ 
ed  through  pooling  funds  across  SPOs  or  direct  core  funding  of  the  engineering  center.  Under 
this  concept  of  operations,  the  engineering  center  is  the  designated  developer  of  the  system 
and  also  sustains  the  product  line  and  its  assets.  Figure  6  illustrates  responsibilities  of  the 
product  line  engineering  center  and  the  SPO. 


Figure  6:  SPO  and  Product  Line  Center  Responsibilities 
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The  product  line  approach  allows  early  demonstration  of  capabilities  to  the  user  through  a 
baseline  system  supporting  rapid  prototyping  and  existing  products  in  the  product  line.  This 
early  demonstration  informs  the  user  of 

•  how  other  products  look  (i.e.,  capabilities,  structure,  performance 
characteristics,  etc.) 

•  the  bounds  of  tailoring 

•  how  requirements  should  be  analyzed  and  how  to  manage  expectations 

•  what  are  areas  of  risk,  i.e.,  those  not  currently  covered  by  the  product  line 
Through  demonstration,  the  user  can  then  determine  whether  the  product  line  approach  will 
be  sufficient  to  meet  all  or  a  subset  of  the  user’s  needs. 

3.3.2  Tailoring  the  Product  Line  Architecture 

Systems  acquired  by  the  SPO  involve  different  groups  depending  on  the  specific  system  re¬ 
quirements  for  that  acquisition.  The  engineering  center  interacts  with  the  Systems  Architec¬ 
ture  Group  and  the  Product  Line  Asset  Support  group  in  system  development.  Figure  7  shows 
the  relationship  between  the  Product  Line  Engineering  Center  and  the  other  organizations  in¬ 
volved  in  product  lines: 

•  The  SPO  provides  the  system  requirements  and  a  direct  interface  to  the  user 
community  for  the  production  of  systems  in  the  product  line. 

•  The  System  Architectures  Group  (SAG)  works  with  the  engineering  center  in 
product  line  architecture  definition  and  during  product  development,  works 
with  the  SPO  and  engineering  center  in  selecting  and  evolving  the 
architecture, 

•  The  Product  Line  Asset  Support  Group  (PLAS)  works  with  the  engineering 
center  to  install  the  product  line  assets  and  during  product  development, 
identifies  and  qualifies  new  assets. 

The  product  line  engineering  center,  working  with  the  other  product  line  organizations,  per¬ 
forms  the  three  key  tasks  of  product  line  production: 

1 .  Support  definition  and  maintenance  of  product  line  architecture. 

2.  Develop,  evolve,  and  maintain  product  line  assets. 

3.  Produce  application  systems  (including  systems  that  integrate  across  product 
lines). 
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The  product  line  architecture  is  driven  by  system  requirements,  thus  establishing  the  design 
structure  for  systems  in  the  product  line.  The  two-headed  “Architecture”  arrow  indicates  that 
the  specific  needs  of  a  system  in  the  product  line  will  influence  evolution  of  the  architecture. 
The  assets  satisfy  particular  functional  capabilities  common  to  systems  in  the  product  line  or 
support  some  aspect  of  product  development  (e.g.,  testing,  documentation).  They  supply  the 
key  components  used  in  building  systems  in  the  product  line.  The  two-headed  “Assets”  arrow 
indicates  that  system  needs  will  also  influence  the  evolution  of  the  product  line  assets.  The 
third  task  is  the  development  and  production  of  application  systems.  Application  systems 
are  the  successful  integration  of  product  line  architectures  and  assets  together  with  any 
unique,  newly-developed,  or  identified  commercial  components  that  are  necessary  to  fulfill  a 
particular  need  of  the  system.  These  unique  components  become  candidates  for  the  asset 
base  for  future  product  line  development. 

3.3.3  Developing  Systems  with  Product  Line  Assets 

Figure  8  shows  the  process  of  delivering  a  software  system  or  product.  When  a  new  product 
need  is  identified,  the  appropriate  product  line  engineering  center  will  work  with  a  SPO  and, 
through  application  engineering,  produce  a  system  meeting  that  need.  Alternatively,  the  SPO 
may  task  the  engineering  center  to  provide  assets  to  a  contractor  or  directly  to  a  user  organi¬ 
zation  for  development.  The  alternative  means  of  product  development  offer  tremendous  flex¬ 
ibility  to  the  SPO,  yet  retain  the  structure  and  consistency  of  the  product  line  approach  and 
avoid  unnecessary  duplication  of  effort  and  expenditure  of  scarce  resources. 
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The  figure  illustrates  that  Product  Lines  A  and  B  are  established  within  the  engineering  center. 
Product  Line  A  has  two  existing  products,  A1  and  A2.  The  SPO  and  user  have  teamed  with 
the  engineering  center  and  architecture  group  to  understand  the  existing  products  within  the 
product  line,  the  range  of  capabilities  offered  by  Product  Line  A,  and  the  ability  of  the  engineer¬ 
ing  center  to  tailor  product  line  assets  in  order  to  determine  suitability  of  the  product  line  for 
their  new  needs. 


Description  of  new 
product  need 

SPO,  User,  and 
architecture  group 


0 

0 


Application 

Engineering 


Core 

Competency 
(from  Domain 
Engineering) 


Figure  8:  Product  Line  Systems  Production  Approach 

The  new  product  labeled  A3  is  developed  mainly  by  integrating  reusable  assets  plus  new  soft¬ 
ware  written  specifically  for  A3,  in  accordance  with  a  product  line  architecture  asset.  The  asset 
technology  base  represents  the  core  competency,  or  product  line  knowledge  of  the  engineer¬ 
ing  center.  The  asset  group  assists  the  product  line  center  in  identifying  through  domain  engi¬ 
neering  new  assets  not  currently  in  the  asset  technology  base,.  These  assets  can  support  the 
development  of  A3.  The  asset  group  also  helps  determine  whether  custom  software  written 
for  A3  should  become  assets  for  future  system  production  in  the  product  line. 

Figure  9  shows  the  use  of  a  common  architecture  to  integrate  alternative  product  line  assets 
in  creating  products  for  product  line  A.  Product  A3  must  meet  the  user  requirements  ex¬ 
pressed  in  the  description  of  new  product  need  from  Figure  8.  Product  A1  in  the  figure  uses  a 
mapping  asset  and  two  communication  interfaces  as  well  as  other  components  not  part  of  the 
current  asset  base.  The  new  Product  A3  uses  a  different  mapping  asset  and  one  of  the  same 
communications  assets.  Both  share  the  common  command  center  architecture  asset. 
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Figure  9;  Building  Systems  from  Product  Line  Assets 


The  following  table  summarizes  the  responsibilities  of  organizational  elements. 


Element 

Primary  roles  and  responsibilities 

User 

•  defines  and  prioritizes  user  needs  and  clarifies  requirements 

•  analyzes  prototypes 

•  validates  prototype  results,  where  appropriate 

•  determines  which,  if  any,  of  the  original  requirements  can  be  tai¬ 
lored  to  conform  to  product  line  standards 

•  performs  acceptance  testing  of  delivered  systems 

•  uses  delivered  systems 

Program  Executive 
Office(PEO)  and 
Designated  Acqui¬ 
sition  Commander 
(DAC) 

•  establishes  policy  for  product  line  systems  approach;  policy  for 
integrating  across  product  lines  and  interoperability 

•  ensures  all  programs  are  identified 

•  approves  identification  of  product  lines 

•  identifies  and  reserves  funds  for  product  line  creation  and  develop¬ 
ment 

•  approves  each  system  to  be  developed  under  the  product  line  ap¬ 
proach 

System  Program 
Office(SPO) 

Government 

•  manages  system  acquisition  and  development 

•  serves  as  the  primary  interface  to  users  and  between  other 
product  line  groups 

•  performs  product  line  identification 

•  uses  product  line  definition  to  assist  in  dialog  with  user  for 
deriving  operational  requirements  for  systems 

•  develops  plans  for  integration  across  product  lines 

•  manages  deployment  and  installation 

Table  1 :  Responsibilities  of  Product  Line  Organizations 
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Element 

Primary  roles  and  responsibilities 

System  Architec¬ 
tures  Group 

Government 

/Industry 

•  establishes,  monitors,  and  improves  the  ESC-wide  processes 
used  in  the  product  line  approach 

•  identiffes  product  lines  with  SPOs 

•  with  engineering  centers,  SPOs,  and  users,  defines  and 
maintains  the  architectures  for  ESC  systems 

•  with  engineering  centers,  supports  the  evolution  and 
reengineering  of  legacy  systems  for  conformance  to  product 
line  architecture 

•  defines  standards  and  methods  for  validating  conformance 
with  architectural  definitions;  responsible  for  “building  permits” 
and  certifying  conformance 

Product  Line  Engi¬ 
neering  Center 

Industry^ 

•  defines  and  maintains  architectures  for  product  lines  within  the 
engineering  center  and  for  integration  across  product  lines 

•  develops,  procures,  and  evolves  software  (including  COTS 
software)  for  product  lines  and  for  product  line  assets; 
configuration  management 

•  integrates  and  delivers  systems  by  tailoring  the  product  line 
architecture,  specialization,  and  custom  development  per 

SPO  requirements 

•  supplies  domain  expertise  in  key  product  line  technology 
areas 

•  provides  contract  vehicle  for  use  by  SPO  for  product  delivery 

Product  Line  Asset 
Support  Group 

Industry^ 

•  qualifies  products  against  product  line  architectures 

•  identifies  enterprise-wide  assets  (from  COTS,  GOTS,  product 
line  engineering  centers) 

•  provides  a  repository  for  ESC-wide  engineering  center  use 

Table  1:  Responsibilities  of  Product  Line  Organizations 


a.  This  organization  is  Government-staffed  and  managed. 

b.  This  organization  is  joint  Government/industry,  managed  by  government. 

c.  These  organizations  are  industry-staffed  and  managed,  with  Government  oversight. 

The  PEO  and  DAC  are  entirely  Government  organizations  and  represent  Government  users. 
The  other  organizations  shown  in  Table  1  are  a  mix  of  government  and  contractors.These  or¬ 
ganizations  exist  to  support  the  product  line  approach  to  acquisition  and  development.  Under 
this  structure,  each  engineering  center  is  supported  by  contractors  that  produce  products  in 
specific  product  lines. 


3.3.4  Integrating  Systems  Across  Product  Lines 

A  product  may  require  capabilities  drawn  from  product  lines  in  two  or  more  product  line  engi¬ 
neering  centers.  The  enterprise-wide  processes  used  in  the  product  line  approach  ease  the 
integration  of  systems  that  cross  product  line  boundaries.  In  Figure  10,  Product  Line  Engineer¬ 
ing  Centers  2  and  3  include  product  lines  indicated  by  the  icons  for  each  center.  Architectures 
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and  other  assets  from  the  product  lines  are  both  specialized  (i.e.,  taiiored  to  the  specific  sys¬ 
tem  needs)  and  integrated  to  produce  finished  products  for  the  user.  For  exampie,  a  user  may 
need  an  integrated  information  distribution  system.  There  may  be  individual  product  line  cen¬ 
ters  for  radio  communication  and  message/text  processing.  In  this  case,  a  SPO  will  either  se¬ 
lect  an  integration  contractor  to  provide  the  focus  of  the  development  or  contract  through  an 
engineering  center  to  produce  the  integrated  system.  While  the  SPO  directs  the  specialization 
to  meet  customer  needs,  the  process  of  specialization/integration  will  be  the  responsibility  of 
the  integrating  contractor  or  of  the  product  line  engineering  center  selected  by  the  SPO  as  in¬ 
tegrator. 


Specialization  ^ -  SPOs  - ►  Integration 


% 


Product  Line 
Engineering  Center  1 


PL  #1  Architecture 

1 

Product  Line 
Engineering  Center  2 


PL  #2  Architecture 

Product  Line 
Engineering  Center  3 


PL  #3  Architecture 

1 

Figure  10:  From  Assets  to  Products 

Table  2  describes  the  various  development  approaches  to  integration.  The  table  lists  four  al¬ 
ternate  approaches  for  developing  products  that  integrate  across  multiple  product  lines  or  en¬ 
gineering  centers.  These  four  approaches  offer  ESC  a  range  of  selections  for  developing 
systems  that  integrate  across  product  lines. 


Integrator 

Description 

Contractor 

The  SPO  works  with  a  single  integration  contractor  that 
utilizes  and  integrates  products  from  individual  product 
lines. 

Engineering  center 

An  individual  engineering  center  is  designated  as  lead 
center.  The  SPO  uses  an  existing  contract  available 
within  the  lead  center  to  secure  an  integrating  contractor. 
The  integrating  contractor  draws  assets  from  the  Asset 
Support  Group  and  works  with  other  centers  to  integrate 
a  final  product. 

Table  2:  Alternative  Development  Approaches  for  Integrated  Systems 
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integrator 

Description 

SPO 

The  SPO  acts  as  the  integrator,  drawing  resources  from 
several  centers. 

Integration  center 

A  new  center  is  opened  specifically  to  develop  a  product 
line  (or  product  lines)  of  integrated  C^l  products. 

Table  2:  Alternative  Development  Approaches  for  Integrated  Systems 


3.3.5  Maintaining  Software  Systems  in  the  Product  Line 

The  product  line  approach  to  maintenance  requires  continued  use  and  improvement  of  the 
product  line  assets  used  during  initial  development.  A  SPO  initiates  a  need  for  product  im¬ 
provement,  whether  corrective,  perfective,  or  enhancing.  Maintaining  the  system  also  entails 
maintaining  the  product  line  assets  and  modifying  or  extending  them,  if  required,  to  meet  the 
customer’s  needs  for  product  improvement.  Maintenance  may  also  take  advantage  of  assets 
that  have  been  added  to  the  asset  base  or  improved  by  other  system  developments  in  the  spe¬ 
cific  product  line  or  in  other  product  lines.  Configuration  management  (CM)  of  assets  will  be  a 
component  of  the  infrastructure  maintained  by  the  asset  support  group.  This  CM  system  must 
take  into  account  not  only  versions  for  systems,  but  also  versions  for  assets  used  in  each  field¬ 
ed  system.  As  new  versions  of  assets  become  available,  current  users  must  be  able  to  obtain 
current  configurations  for  these  assets  from  this  CM  system  and  update  their  systems. 

Several  critical  issues  must  be  resolved  to  support  this  multitiered  CM.  Among  these  are  the 
following: 

•  If  an  asset  is  upgraded,  other  assets  that  rely  on  it  or  interact  with  it  will  be 
affected.  Maintenance  of  a  system  using  the  asset  may  opt  for  retaining  the 
old  version  to  avoid  a  ripple  effect  of  changes. 

•  At  what  point  in  the  evolution  of  a  product  line  architecture  does  it  become  a 
new  architecture?  The  evolution  may  require  new  assets,  additional 
interfaces,  etc.  All  products  in  the  product  line  will  likely  not  be  upgraded. 

Several  options  exist  for  managing  the  maintenance  of  systems  in  the  product  line: 

1 .  The  original  engineering  center  may  perform  maintenance. 

2.  A  maintenance  center  may  be  designated  for  some  or  all  systems  across 
several  engineering  centers. 

3.  Individual  systems  may  be  maintained  by  the  user  group  or  their  designated 
maintenance  organization. 

Performing  maintenance  outside  the  original  engineering  center  may  place  at  risk  the  contin¬ 
ual  improvement  of  all  systems  in  the  product  line.  It  is  expected  that  the  majority  of  the  main¬ 
tenance  activities  would  be  handled  in  the  same  manner  as  new  system  developments.  The 
SPO  will  fund  a  new  development  effort  that  will  call  upon  the  resources  of  the  product  line 
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(product  line  architecture  and  components)  for  implementation.  As  a  result,  multiple  versions 
of  a  component  will  exist  in  the  product  line  architectures  at  any  given  time.  This  will  result  in 
a  new  dimension  for  configuration  management  to  address. 

3.4  Product  Line  Development  Scenarios 

Below  are  several  scenarios  describing  the  development  of  product  line  assets  and  the  pro¬ 
duction  of  systems  within  a  product  line  using  assets. 

3.4.1  Developing  Product  Line  Assets 

The  Generic  Command  Center  Architecture  (GCCA)  developed  by  the  Portable,  Reusable,  In¬ 
tegrated  Software  Modules  (PRISM)  [Lonardo  93]  program  is  an  example  of  how  product  line 
assets  can  be  developed.  In  this  case,  the  GCCA  is  a  fundamental  asset,  as  it  defines  other 
assets  that  are  necessary  to  develop  applications  in  the  Command  Center  Product  Line.  The 
GCCA  was  developed  in  two  steps.  The  first  was  domain  analysis:  The  analysis  and  develop¬ 
ment  of  a  common  process  flow  for  functions  that  had  to  be  provided  in  a  command  center. 
The  second  step  was  to  map  the  features  of  the  process  diagram  into  a  generic  top-level  de¬ 
sign  for  command  center  systems;  in  other  words,  a  product  line  architecture  that  would  max¬ 
imize  software  reuse.  The  emphasis  was  on  using  commercial  off-the-shelf  (COTS)  software, 
because  analysis  indicated  that  it  was  cheaper.  Therefore,  the  design  was  adjusted  so  that 
COTS  software  could  provide  functionality  without  modification.  The  unique  applications’  soft¬ 
ware  components,  not  available  off-the-shelf,  were  designed  for  as  much  reuse  potential  as 
possible. 

In  some  cases  it  may  be  appropriate  to  adjust  product  line  architectures  to  allow  assets  to  be 
used  in  multiple  product  lines.  The  key  is  to  create  functional  modularity  within  the  product  line 
architectures.  DoD  contractors  have  developed  modular  software  for  years,  but  the  modularity 
was  usually  unique  to  a  particular  design  and  functions  were  not  packaged  in  a  manner  that 
would  facilitate  reuse.  The  COTS  software  industry  has  provided  the  model  of  how  to  design 
packages  with  functional  modularity  so  that  the  software  components  will  have  a  widespread 
application.  These  same  principles  should  be  applied  to  our  product  line  developments. 

Software  assets  are  identified  and  certified  for  use  in  a  specific  system  software  design.  For 
the  command  center  product  line,  these  assets  have  been  primarily  COTS  software,  with  the 
objective  of  certifying  more  than  one  COTS  product  for  each  of  the  functional  modules  /  re¬ 
quirements.  Thus,  the  product  line  architecture  can  be  tailored  to  a  user’s  needs  by  changing 
the  components;  then  users  are  not  dependent  on  a  specific  software  vendor. 

To  remain  viable,  the  product  line  assets  must  be  updated  to  maintain  compatibility  with  evolv¬ 
ing  information  technology  standards  and  functional  software  modules.  New  releases  of 
COTS  products  must  be  evaluated  for  inclusion  into  the  product  line  and  the  impact  on  the 
product  line  must  be  identified  and  demonstrated.  The  product  line  serves  as  a  showcase  of 
previously-delivered  products  and  a  repository  for  the  latest  versions  of  the  product  line  as¬ 
sets. 
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3.4.2  Developing  Products  from  a  Product  Line 

Figure  1 1  illustrates  a  scenario  for  development  within  a  product  line  engineering  center.  The 
Joint  Tactical  Information  Distribution  System  (JTIDS)  today  provides  a  tactical  information 
distribution  system  and  will  serve  as  a  model  for  future  systems  in  the  communications  product 
line.  In  the  figure,  the  JTIDS  SPO  will  team  with  the  System  Architectures  Group  and  engineer¬ 
ing  center  to  identify  the  product  line  and  assets  to  support  a  new  requirement.  The  product 
line  engineering  center  would  then  integrate  capabilities  (including  ground/airborne  communi¬ 
cations  and  message  processing)  within  the  product  engineering  center  to  produce  a  new 
product. 


Figure  1 1 :  Development  Within  Product  Line  Engineering  Center 


3.4.3  Developing  Integrated  Products  Across  Product  Lines 

Development  of  many  ESC  products  depends  on  integration  across  product  lines  and  product 
line  engineering  centers.  The  following  considerations  are  necessary  in  establishing  the  initial 
product  line  engineering  centers  within  ESC: 

•  interconnections  among  product  lines  and  product  line  engineering  centers 

•  rationale  for  definitions  of  boundaries  among  product  lines  and  centers 

•  operational  context  for  product  line  definitions  and  architectures 

The  engineering  centers  and  architectures  group  work  with  SPOs  to  carry  out  this  role.  Exam¬ 
ples  of  “cross-product  line”  group  products  may  include: 

•  TBMCS  -  mission  planning  and  command  centers 

•  Advanced  Message  Handling  System  -  data  fusion  and  command  centers 
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As  an  example,  a  cross-product  line  configuration  can  exist  to  produce  a  new  mission  plan¬ 
ning/battle  management  system.  In  Figure  12,  the  SPO,  engineering  centers,  and  architec¬ 
tures  group  work  together  to  identify  a  lead  product  line  engineering  center  for  the 
development  of  the  new  product.  The  lead  center  works  with  other  centers  to  specialize  prod¬ 
uct  line  capabilities  and  integrate  them  into  a  new  battle  management  product.  The  product 
integrates  the  following: 

•  mission  planning  capabilities  that  accept  data  from  data  fusion  sources  as 
input  and  support  flexible  execution  and  replanning 

•  command  center  capabilities  that  support  situational  displays 


Figure  12:  Integrated  Air  Battle  Management  System 
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Issues  for  the  Transition  Strategy 

4.1  Concept  of  Operations  for  Transition 

The  product  line  approach  is  not  a  case  of  “one  size  fits  all.”  There  may  be  circumstances 
where  the  approach  should  not  be  followed  due  to  cost,  schedule,  performance,  capability,  or 
insufficient  commonality.  All  product  lines  may  not  be  of  the  same  maturity,  so  the  procure¬ 
ment  organization  must  consider  risk  factors  in  making  a  product  line  decision.  Finally,  a  new 
set  of  requirements  may  fall  outside  the  bounds  of  any  existing  product  line.  ESC  must  then 
determine  if  this  should  be  a  new  area  for  continuing  work  and  whether  establishing  a  new 
product  line  is  feasible.  All  of  these  factors  would  be  considered  as  part  of  the  business  anal¬ 
ysis. 

To  establish  the  product  line  approach,  ESC  should 

1 .  use  a  pilot  effort  to  serve  as  a  test  case  for  the  product  line  engineering  center 
concept 

2.  identify  an  existing  product  group  to  institute  product  line  management 
strategies 

3.  identify  an  existing  program  or  SPO  to  develop  an  evolution  strategy  for 
moving  to  a  product  line  approach 

After  the  initial  approach  is  established,  ESC  should 

1 .  Create  the  System  Architectures  Group,  Product  Line  Engineering  Centers 
and  Product  Line  Asset  Support  Group  to  support  product  line  production  and 
qualification  of  assets.  These  organizations  are  not  created  for  every  new 
product  line,  only  when  existing  centers  cannot  or  should  not  support  a  new 
product  line. 

2.  Analyze  the  current  product  mix  to  identify  potential  product  lines.  This  is  the 
effort  reported  in  Product  Line  Identification  for  ESC-Hansom  [Cohen  95]. 

The  analysis  reviews  the  current  status  of  an  organization’s  programs  and  the 
plans  for  future  evolution.  The  organization  must  consider  its  current  and 
anticipated  customer  base.  It  is  possible  that  ongoing  programs  will  need 
resources  and/or  relief  in  program  milestones  to  assist  in  the  development  of 
the  asset  base  and  transition  to  product  lines. 

3.  Define  the  assets  for  product  line  development  according  to  desired  product 
variety  and  customer  needs.  ESC  must  identify  the  processes  that  are  part  of 
asset  creation  including  domain  engineering,  architecture  description  and 
assessment,  and  reengineering  to  deal  with  legacy  systems.  The  System 
Architectures  Group  will  be  responsible  for  defining  and  monitoring  these 
processes  for  the  Product  Line  Engineering  Centers. 

Along  the  transition  path,  ESC  should  look  for  new  or  ongoing  programs  that  can  immediately 
contribute  to  the  product  line  approach.  The  Systems  Architecture  Group  should  seek  ways  to 
develop  architectures  and  work  with  ongoing  programs,  e.g..  Global  Command  and  Control 
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Systems  (GCCS),  Regional/Sector  Operations  Command  Center  (R/SOCC),  Theatre  Battle 
Management  (TBM),  Space  and  Warning  Systems  Directorate,  to  make  sure  these  systems 
produce  common  product  line  assets,  or  that  the  components  they  produce  can  become  prod¬ 
uct  line  assets. 

4.2  impact  of  T ransition 

The  transition  to  a  product  line  strategy  requires  significant  change  in  the  existing  organiza¬ 
tions.  The  plan  for  transition  must  address  the  impact  of  change  on  organizational,  manage¬ 
ment,  and  acquisition  elements. 

4.2.1  Organizational 

ESC  is  currently  experiencing  a  significant  decline  in  resources  and  will  need  new  organiza¬ 
tional  structures  to  utilize  successfully  the  remaining  resources.  The  product  line  approach  will 
require  special  attention  to  bring  together  core  competencies  from  across  existing  organiza¬ 
tional  structures.  There  appears  to  be  significant  redundancy  of  personnel  and  skills  within  the 
current  two-letter  organizations.  Product  line  organizational  restructuring  will  enable  concen¬ 
tration  and  sharing  of  personnel  and  skills. 

While  the  establishment  of  a  product  line  philosophy  will  affect  product  users,  PEOs,  contrac¬ 
tors,  and  support  organizations,  the  principal  effect  will  be  on  the  direct  users  of  the  product 
lines:  the  SPOs.  SPOs  will  coordinate  the  interaction  of  users,  the  architectures  group,  and 
the  Product  Line  Engineering  Centers  for  proposed  systems.  The  SPO  will  rely  on  the  engi¬ 
neering  centers  for  technology  expertise  and  development  and  on  the  engineering  center,  to¬ 
gether  with  the  architectures  group  and  the  Asset  Support  Group,  to  establish  the  specifics  for 
system  implementation  and  for  configuration  management  as  it  affects  the  product  line.  The 
SPO  will  then  choose  a  contractor,  either  from  the  set  of  PLEC  contractors  or  elsewhere,  to 
implement  the  system.  During  product  sustainment,  the  SPO  will  review  the  existing  product 
lines  and  architectures  and  establish  a  reasonable  maintenance/upgrade/enhancement  plan 
for  the  product. 

4.2.2  Management 

New  incentives  will  be  needed  to  support  the  management  and  use  of  a  product  line  approach. 
Organization  elements  of  key  importance  to  ESC  will  be  smaller  than  they  are  today,  but  no 
less  critical.  The  following  steps  will  help  manage  the  technological  changes  that  come  with 
adopting  a  product  line  approach: 

1 .  Promotion  and  reward  potential  must  be  addressed  in  the  new  structure. 

2.  General  cultural  changes  will  be  needed  at  all  levels.  Management  must  drive 
these  changes,  even  when  they  are  the  most  affected. 

3.  Organizational  elements  will  need  to  learn  to  get  their  job  done,  i.e.,  field  a 
system,  by  relying  on  support  and  assets  from  other  organizational  elements. 

Not  all  aspects  of  a  program  will  be  under  the  control  of  one  manager. 
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4.  Product  line  orientation  requires  sharing  of  responsibilities  and  is  impossible 
in  a  stovepiped  organizational  structure. 

5.  A  managed  process  for  product  line  development  will  support  certification  of 
system  conformance  to  the  product  line  architecture  and  successful  use  of 
product  line  assets. 

4.2.3  Acquisition 

Systems  need  to  be  acquired  through  methods  that  encourage  the  use  of  existing  product  line 
infrastructure  and  directly  support  the  maintenance  and  upgrade  of  the  infrastructure  to  sup¬ 
port  future  needs.  The  current  acquisition  process  funds  software-intensive  efforts  on  a  pro¬ 
gram-by-program  basis,  with  minimal  funding  allocated  to  product  line  infrastructure.  Such 
investment  is  needed  in  support  of  a  series  of  systems  based  on  a  common  infrastructure. 
While  significant  changes  are  needed  in  the  Program  Objectives  Memorandum  (POM)  pro¬ 
cess  to  get  full  benefits  from  product  lines,  ESC  can  address  many  near-term  changes  with 
local  acquisition  strategies.  These  local  acquisition  strategies  include 

•  coordination  of  development  activities  among  program  offices  by  ESC 

•  elimination  of  redundant  development 

•  use  of  funds  to  further  the  development  of  the  product  line  for  the  benefit  of 
all  the  contributing  programs 

ESC  can  also  pool  funds  from  all  the  programs  that  fall  within  a  product  line  to  pursue  product 
line  development  using  product  line  contractors.  ESC  may  designate  one  program  to  establish 
the  common  infrastructure.  Other  program  offices  would  contribute  software  assets  to  evolve 
the  product  line.  Product  line  approaches  also  support  procurement  reform  initiatives  by  taking 
advantage  of  commercial  practices,  existing  COTS  software  products,  and  standardization  of 
newly-developed  product  line  components  that  can  be  reused  across  systems. 

The  PEO  and  DAC  must  ensure  that  every  new  program  is  examined  for  similarities  with  ex¬ 
isting  systems  in  mission  and  underlying  functions.  The  goal  is  to  focus  new  development  on 
unprecedented  areas  and  reuse  product  line  assets  as  much  as  possible.  Reuse  of  assets  in¬ 
cludes  much  more  than  software  components.  Design,  architecture,  requirements,  and  mod¬ 
els  are  all  assets  for  reuse.  Acquisition  strategies  will  need  to  ensure  that  every  procurement 
leverages  to  the  fullest  the  past  investments  and  contributes  to  the  assets  to  be  used  in  future 
efforts. 

Due  to  the  increased  focus  on  assets  (including  non-code  assets,  such  as  architectures)  and 
their  management  for  use  across  more  than  one  system,  product  lines  will  bring  ownership 
and  liability  issues  to  the  forefront.  The  current  acquisition  regulations  define  a  range  of  op¬ 
tions  for  software  and  data  rights,  ownership,  and  liability  issues  that  are  most  likely  sufficient 
to  address  product  line  implementation.  While  the  current  acquisition  guidelines  provide  a 
sound  framework  for  dealing  with  issues  of  ownership  and  asset  management,  additional 
guidance  on  their  application  to  product  line  concepts  will  be  needed. 
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Ownership  of  assets  within  the  product  line  approach  is  a  key  question.  The  Government  or¬ 
ganization  should  own  the  product  line  architectures  or  at  least  the  right  to  use  the  architec¬ 
tures.  The  product  line  and  the  non-COTS  software  built  to  field  a  system  may  be  government- 
or  industry-owned.  One  model  for  the  organizational  structure  of  product  line  assets  is 

1.  Government  -  Defines  and  owns  Government  Purpose  License  Rights 
(GPLR)  to  product  line  architectures  to  define  component  structure,  connec¬ 
tions,  and  constraints  for  a  class  of  systems. 

2.  Industry  -  Develops  components  driven  by  market  need  and  integrates 
components  as  part  of  a  system  within  a  product  line.  The  government 
obtains  GPLR  while  the  contractor  retains  commercial  rights. 

4.3  Support  Strategy 

A  basic  element  of  the  product  line  strategy  is  the  continued  maintenance  and  enhancement 
of  the  product  lines  and  the  corresponding  architectures.  The  SAG,  the  PLAS,  and  the  PLECs 
will  cooperate  in  this  effort,  with  the  architecture  group  taking  the  lead.  Architecture  mainte¬ 
nance  and  enhancement  is  the  primary  responsibility  of  the  SAG,  which  will  lead  architectural 
assessments  to  determine  the  needs  for  enhancement  or,  possibly,  a  new  architecture.  The 
PLEC  is  responsible  for  actual  enhancements  to  the  architecture  and  for  fixing  bugs  in  product 
line  components  and  ensuring  that  new  versions  of  COTS  products  are  integrated  into  the 
product  lines.The  PLAS  is  responsible  for  maintaining  the  Product  List  supporting  the  product 
lines  and  for  working  with  vendors  to  coordinate  maintenance  of  their  products.  Updated  prod¬ 
ucts  are  provided  to  the  various  customers/users  according  to  maintenance/upgrade  agree¬ 
ments  established  at  the  initiation  of  a  system  acquisition.  The  maintenance  and  support  of 
the  product  line  architectures  and  components  is  a  natural  consequence  of  the  product  line 
development  strategy. 
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5  Benefits  and  Challenges 

By  using  the  product  line  systems  approach,  organizations  will  deploy  systems  faster,  at  a  low¬ 
er  cost,  and  with  fewer  Government  and  industry  resources.  Systems  wi'  be  even  more  reli¬ 
able  because  they  will  use  common  components  that  will  have  high  reliability  and  proven 
performance  characteristics.  Training  will  be  improved  since  common  components  will  reduce 
the  amount  of  training  currently  needed  when  transitioning  between  command  and  control 
systems.  More  commercial  components  will  be  available  because  industry  will  identify  a  larger 
market  for  their  products  when  used  across  similar  systems.  Upgrades  of  components  will  also 
be  promoted  as  industry  recognizes  a  new  market  for  their  enhanced  products. 

The  successful  implementation  of  a  product  line  systems  approach  presents  challenges  and 
barriers  that  are  significant  but  surmountable.  These  include 

•  Cultural  -  Product  line  strategies  mean  organizations  and  managers  have 
less  direct  control  over  their  product  developments  and  increased 
dependency  on  other  organizations  to  understand  their  requirements  and 
provide  acceptable  solutions.  Giving  up  this  control  and  the  necessary 
dollars  to  support  product  line  technology  and  application  development  may 
be  difficult. 

•  Strategic  planning  -  Product  line  planning  is  not  only  a  management 
process  that  links  related  systems.  The  PEO  or  DAC,  who  have  oversight  for 
numbers  of  product  lines,  must  consider  the  long-term  needs  of  users  and 
the  ability  of  ESC  to  build  for  those  users.  They  must  take  an  enterprise-wide 
look  at  existing  and  planned  products  and  look  several  years  into  the  future 
in  planning  for  product  lines.  The  future  year  development  plan  (FYDEP) 
should  focus  attention  on  product  lines  as  the  means  to  satisfy  the  plan. 

•  Need  for  tradeoffs  -  The  product  line  approach  presents  a  tradeoff  for  the 
user  between  “build  me  the  exact  system  I  wanf  and  “build  me  a  system 
almost  like  what  I  want  using  the  product  line,  saving  on  costs  and  time.” 

•  Resource  ownership  -  Who  will  “own”  the  product  line  components?  How 
will  they  be  funded?  These  issues  require  PEOs  and  DACs,  as  well  as  the 
Air  Force  Acquisition  Secretariat,  to  accept  transitioning  from  program- 
focused  acquisition  organizations  and  budgets  to  more  commercial-like 
product  organizations  and  budgets. 

•  Recognition  and  reward  -The  current  acquisition  system  focuses 
recognition  and  rewards  for  personnel  on  delivered  systems.  Use  of  product 
line  strategies  necessitates  a  shift  to  also  rewarding  and  advancing 
personnel  for  broadening  the  utility  of  products  and  facilitating  their  use  within 
and  across  product  lines. 

•  User  interface  -  Users  will  experience  close  ties  to  the  development 
organization  within  the  engineering  center.  They  should  experience  greater 
responsiveness  through  improved  needs  definition,  refinement,  and  early 
demonstration.  However,  operational  users  must  adjust  to  having  more  than 
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the  program  manager,  PEO,  or  DAC  as  their  dependency  links  to  successful 
system  upgrades  or  developments.  This  should  not  be  difficult  since  users 
today  are  regularly  dependent  on  a  variety  of  sources  for  successful  systems 
deliveries. 

•  Effects  of  technological  change  -  The  transition  to  a  product  line  approach 
will  mean  significant  changes  in  our  current  way  of  doing  business.  We  must 
plan  for  the  effects  this  will  have  on  the  individuals  who  must  carry  out  the 
transition  and  also  on  those  who  will  be  operating  under  the  new  approach. 

In  spite  of  the  magnitude  of  these  issues,  the  transition  can  likely  be  achieved  within  existing 
budget  planning. 
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6  Summary 

The  product  line  approach  will  not  fit  all  system  solutions,  but  should  make  a  significant  im¬ 
provement  in  the  timeliness,  cost,  and  reliability  of  systems  that  are  found  to  be  suitable  for  its 
application.  The  business  analysis  must  determine  where  and  how  to  apply  the  product  line 
concept  of  operations. 

Use  of  product  line  strategies  wiii  enhance  reliability  of  performance,  schedule,  and  cost  esti¬ 
mates.  This  dependability  in  delivery  of  systems  will  be  achieved  through  elimination  or  nar¬ 
rowing  of  the  “bounds  of  uncertainty”  that  accompany  any  estimating  process.  Where  proven 
components  are  incorporated  into  the  design  and  estimating  process,  we  immediately  improve 
our  confidence  levels  surrounding  performance,  schedule,  and  cost  expectations.  Our  assess¬ 
ments  of  risks  and  the  uncertainties  associated  with  resolving  those  risks  are  more  narrowly 
bounded  because  of  the  improved  ability  to  bound  the  expectations  associated  with  use  of 
product  line  components.  Metrics  are  more  readily  available  to  assist  in  the  estimating  process 
and  establishment  of  schedule  and  performance  parameters. 

Adoption  of  the  product  line  approach  requires  thorough  business  analysis  and  careful  plan¬ 
ning.  An  organization  must  assess  the  business  opportunities  to  ensure  the  appropriateness 
of  adopting  a  product  line  approach.  During  transition,  the  organization  must  carefully  monitor 
progress  and  make  sure  that  product  line  groups  are  giving  effective  support  to  the  SPOs. 

Contractors  work  with  several  related  programs  to  develop  a  common  architecture  and  other 
assets.  While  it  is  not  necessary  for  the  Government  to  own  all  the  assets  in  the  product  line 
asset  base,  it  is  necessary  to  have  appropriate  access  to  them.  The  acquisition  and  ownership 
policy  for  product  line  architectures  is  under  investigation  by  several  groups  within  the  DoD. 
Implementation  plans  derived  from  this  ConOps  will  include  the  results  of  these  investigations 
to  support  decisions  about  responsibility  and  accountability. 

Product  line  development  evolves  naturally  from  applying  fundamental  engineering  concepts 
to  meeting  recurring  needs.  Recurring  requirements  provide  the  potential  for  economies  of 
scale  and  reuse.  Doing  the  job  better,  faster,  and  cheaper  requires  a  focus  on  efforts  that  re¬ 
duce  the  variable  costs  associated  with  system  development  and  the  total  life  cycle. 
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